Using SRV records for redundancy and server discovery in Presence, Jabber and CUCM

Using SRV records for redundancy and server discovery in Presence, Jabber and CUCM

As most of the time, I stumbled across this topic, and I was really thinking about posting something about UCCX again, but things change dont they. Especially when working on tightly scoped, well documented and designed implementation, ;-).

I have never really given the possibilities of using SRV records much thought, so most of this post is a bit of research for myself as well


Before I go into SRV records, here is a definition, for those who are not yet familiar with the mechanism.


DNS records consist of a series of entries that match a server name to a single IP address in a networked environment. Every one knows this! DNS SRV records differ in that they match a service with a server (hostname), or set of servers, in a networked environment.  In doing this, DNS SRV allows a client to only have to know what type of service it is looking for instead of the actual server.  This aids deployment, server management, and service failover because most networked environments have multiple, load balanced servers attending to the needs of a particular service.

 

As you can see in the table below, there are a good few services that can be requested/discovered from the various Collaboration clients, using the mechanism of SRV records.
 
Service DNS SRV Record
Cisco WebEx Messenger _xmpp-client._tcp
Cisco Unified Presence _cuplogin._tcp
Cisco Unified Communications Manager TFTP _cisco-phone-tftp._tcp
Cisco Unified Communications Manager CCMCIP _cisco-phone-http._tcp
Cisco TelePresence Video Communication Server (Internal) _sip._tcp.internal
Cisco TelePresence Video Communication Server (External) _sip._tcp.external
Cisco Jabber Video for TelePresence _ciscowtp._tcp
Cisco WebEx TelePresence _ciscowtp._tcp

source: http://www.cisco.com/en/US/docs/voice_ip_comm/jabber/iPad/9_x/JABP_BK_J3C828CB_00_jabber-for-ipad-admin_chapter_01000.html

(On Jabber TFTP and CCMCIP will not be used as they are pushed out by CUPS as soon as a user logs in, through CCMCIP profile and TFTP server settings in CUPS). 


Applications:

SRV records are an easy way to build  a redundant SIP Publish trunk between CUCM and CUPS. (The conventional way would be to add to separate destinations, using port 5060, in the screenshot below. You could argue that that would be a more robust way, when using IP addresses i.e. no DNS dependency).

 

 

As you can see below, the SIP trunk configured on the CUCM side, is configured as presence.lala.com.au. The Destination address is SRV is ticked.

The DNS SRV record for _sip._tcp is set up to point to two different CUPS servers, with varying priority.

Test redundancy and SRV records out, by issuing:

nslookup
> set type=srv
> _sip._tcp.presence.lala.com.au   <—–this is your SRV destination address
Server:  lala.com.au
Address:  89.10.10.10

_sip._tcp.presence.lala.com.au       SRV service location:
priority       = 20
weight         = 0
port           = 5060
svr hostname   = bun-cups-sub.lala.com.au
_sip._tcp.presence.lala.com.au       SRV service location:
priority       = 10
weight         = 0
port           = 5060
svr hostname   = bun-cups-pub.lala.com.au
lala.com.au  nameserver = s1.lala.com.au
lala.com.au  nameserver = s2.lala.com.au
bun-cups-pub.lala.com.au     internet address = 10.11.255.21
bun-cups-sub.lala.com.au     internet address = 10.11.255.41
s1.lala.com.au     internet address = 89.10.10.10
s2.lala.com.au     internet address = 89.10.10.10

as you can see, the SRV record returns two servers, one CUPS subscriber and one CUPS Publisher.

Automatic Server discovery (Jabber for Windows only)

You can also use SRV records, to do Automatic Server discovery for Jabber. This makes deployment a bit easier as users do not have to manually type in the presence server host address.
This is required when you use the default server as the login server for Jabber for Windows. (automatic server discovery does NOT work with iphone and ipad where a CUPS hostname or IP address is required).

 

It is my understanding that this will also use _sip._tcp, but according to the

> _cuplogin._tcp.lala.com.au
Server:  s2.lala.com.au
Address:  131.172.2.2

_cuplogin._tcp.lala.com.au   SRV service location:
priority       = 20
weight         = 0
port           = 8443
svr hostname   = bun-cups-sub.lala.com.au
_cuplogin._tcp.lala.com.au   SRV service location:
priority       = 10
weight         = 0
port           = 8443
svr hostname   = bun-cups-pub.lala.com.au
lala.com.au  nameserver = s1.lala.com.au
lala.com.au  nameserver = s2.lala.com.au
bun-cups-pub.lala.com.au     internet address = 10.11.255.21
bun-cups-sub.lala.com.au     internet address = 10.11.255.41
s1.lala.com.au     internet address = 89.172.2.10
s2.lala.com.au     internet address = 89.172.2.11
>

Reference:
http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english/install_upgrade/deployment/guide/deploy.html

Hope this post is usefull, and inspired you to look into the possibilities that SRV record can provide